Multiple-protocol label switching (MPLS) is a system for rapid data packet exchange and routing, which provides capabilities, such as, targeting, routing, forwarding, exchanging and the like to network data traffic. It provides a mode for mapping IP address into a simple label having a fixed length, for use in different packets forwarding and exchanging techniques. In the MPLS network, the node, switcher or router supporting the MPLS are generally termed as Label Switched Router (LSR) and the LSR at the edge (ingress or egress) of the MPLS network is generally termed as Label Edge Router (LER). MPLS, as a classification forwarding technique, classifies groups having the same forward processing way into one class, called Forwarding Equivalence Class (FEC). The groups with the same forwarding equivalence class shall be processed in the same way in the MPLS network. The path passed through by one forwarding equivalence class in the MPLS network is termed as Label Switched Path (LSP).
MPLS LSP ping has been introduced into MPLS network as a simple yet efficient mechanism to detect data plane failure in multiple-protocol label switching (MPLS) Label Switched Paths (LSPs) (see details in RFC4379 “Detecting Multiple-Protocol Label Switched (MPLS) Data Plane Failures”, February, 2006). The basic idea is to verify that packets that belong to a particular Forwarding Equivalence Class (FEC) actually end their MPLS path on a Label Switching Router (LSR) that is an egress for that FEC. This test can be carried out by sending a packet (called an “MPLS echo request”) along the same data path as other packets belonging to this FEC. MPLS echo request also carries information about FEC. MPLS path of the FEC is being verified. This echo request is forwarded just like any other packet belonging to that FEC. In “ping” mode (basic connectivity check), the packet should reach the end of the path, at which point it is sent to the control plane of the egress LSR, which then verifies whether it is indeed an egress for the FEC (see details in RFC4379 mentioned above).
The initial proposal of LSP Ping mechanism is intended for unidirectional LSP check. LSPs, however, are increasingly being deployed to provide bidirectional services. The co-routed bidirectional LSP is defined in RFC3471 “Generalized Multiple-Protocol Label Switching (GMPLS) Signaling Functional Description” (January, 2003) and RFC3473 “Generalized Multiple-protocol label switching (GMPLS) signaling resource reservation protocol-Traffic engineering (RSVP-TE) extensions (January, 2003), and the associated bidirectional LSP is defined in RFC5645 “Requirement of an MPLS Transport Profile” (September, 2009)”. With the deployment of such services, operators have a desire to test both directions of a bidirectional LSP in a single operation.
Furthermore, an LSP such as multi-segment pseudo-wire (MS-PW) can span across multiple service provider networks. In order to allow service providers to verify segments of such MS-PW, any node along the path of the MS-PW, should be able to originate an LSP-Ping echo request packet to any other node along the path of the MS-PW and receive the corresponding echo reply. The LSP ping at intermediate LSR along bidirectional LSPs can be triggered at the LER by issuing remote command through out-of-band connectivity such as IP routes to the intermediate node or started directly by network administrator at the intermediate node in the LSP.
In summary, we need to extend the LSP Ping mechanism to not only support bidirectional LSP check in a single operation (including co-routed bidirectional LSPs and associated bidirectional LSPs), but also support LSP check from any intermediate node along the LSP to any other node in these bidirectional LSPs.
In RFC 4379, the LSP Ping echo request is sent as a UDP (User data Packet) data packet, which includes the initiator's routable IP address as source and a 127/8 address as destination to force the request not to be IP forwarded, but MPLS forwarded. The request once reaches its destination node, triggers an echo reply from the destination node. The destination node then sets the source address of the echo request as the destination IP address of its echo reply message and sends the reply back to the request initiator.
This original design, however, doesn't work for bidirectional LSPs because the echo reply also needs to be MPLS forwarded through the backward LSP, instead of through other routes, so that the backward LSP can be checked in one operation. With the existing LSP ping mechanism, operators have to enable LSP detection on each of the two ends of a bidirectional LSP independently. This not only doubles the workload for the operators, but also brings additional difficulties when checking the backward direction of the LSP under the following conditions:
1. The LSR that the operator logged on to perform the checking operations might not have out-of-band connectivity to the LSR at the far end of the LSP. That can mean it is not possible to check the return direction of a bidirectional LSP in a single operation. The operator must log on to the LSR at the other end of the LSP to test the return direction.
2. The LSP being tested might be an inter-domain/inter-AS LSP where the operator of one domain/AS may have no right to log on to the LSR at the other end of the LSP since this LSR resides in another domain/AS. That can make it completely impossible for the operator to check the return direction of a bidirectional LSP.
These issues apply to both co-routed bidirectional LSPs and associated bidirectional LSPs. (see IETF Draft “Return Path Specified LSP Ping”, October, 2011).
The existing LSP Ping mechanism relies on the IPV4/6 destination address in the echo reply message and the IP route to deliver the reply back to the right LSP ping request initiator. This IP route and destination cannot be used any more when the LSP echo reply packet is MPLS forwarded. The MPLS forwarding makes it a challenge to deliver the echo Reply message back to the echo request initiator for any-to-any LSP ping over bidirectional LSPs.
In the existing LSP ping mechanism, a request packet being sent to the control plane for processing can be triggered by several conditions including: its MPLS TTL expires; the packet reaches a LER; router alert option; or IP TTL expiration. Measuring the hop distance from the echo request initiator to the reply node and then using this hop distance as MPLS TTL for the echo reply message may work for co-routed bidirectional LSPs (see IETF Draft “Definition of Time-to-Live TLV for LSP-Ping Mechanism”, March, 2012), it won't work for associated bidirectional LSPs since the hop distance may differ in the two directions of LSPs. Therefore, we need to find a new way to ensure reply message reaches the right request initiator for all bidirectional LSPs.
Therefore, we need to seek a new method for all the bidirectional LSPs to ensure that reply messages reach right request initiators.